- Published on
Configuration vs Change Control — don’t mix these two
- Authors
- Name
- passpmpnow
The clean mental split
| Topic | It protects | Example |
|---|---|---|
| Configuration Management | the product design / spec consistency | which WBS deliverable version is “official” |
| Change Control | the baseline (scope / schedule / cost) | if a stakeholder wants to add new reporting feature |
If question is about version, spec, correct technical file → Configuration.
If question is about impact to scope/cost/schedule → Change Control.
PMI loves this trap
They will say things like：
“Which system prevents product confusion among teams?”
→ Configuration“Which process validates & decides whether a requested change is allowed?”
→ Integrated Change Control
Ultra short memory aid
Configuration = “which is the right version?”
Change control = “can we even change it?”
When these two touch each other
Real life & exam both：
- change request arrives
- impact analysis says “OK”
- baseline is approved to change
- THEN configuration management will update the new version spec & keep history
流程顺序是：
- Change control → authorizes change
- Configuration mgmt → records & protects the new official version
Most testable stem keyword signals
| If stem says… | Bias toward… |
|---|---|
| version / specification / technical document | Configuration |
| baseline / variance / impact to cost or schedule | Change Control |
| traceability / item indexing / access control | Configuration |
| approval / governance / authority | Change Control |